前言

git 是一種版本控制軟體 (Version Control Software, VCS)，VCS 有很多種，現今最主流的就是 git，而這些 VCS 主要都是針對程式領域的，
git 可以監測任何檔案是否有編輯過，只要有編輯，他就會保留新舊版本，
厲害的是，只要是文字檔案（只有文字沒有格式，可以直接用記事本開啟），就能像這樣指出改了哪些。

此圖使用軟體呈現。

這對於我們昨天寫完，今天就忘的程式碼，有很大的幫助，可以用 GUI 的方式看到來龍去脈，也不用怕把程式改壞，我們也還能隨時到好幾年前，最重要的是，連上遠端後，我們能夠跟其他人協同編輯同一個專案。

基本概念

• Repository（簡稱 repo）：可以說這就是指專案，大部分的情況都是一個 repo 都是一個專案，但並沒有限制。
• Branch：branch 存活在 repo 中，是一個時空的概念，如果要放 code 進去，一定要有 branch，就像我們現在活著的時空就是一個 branch，也許沒有其他時空，但可能也有許多個平行時空，平常大家都在不同的平行時空做事，只有完成任務了，才會把成品都帶到主要的 branch 中。
• Commit：這個字是名詞也是動詞，git 可以幫我們記憶不同改動，而 commit（名詞）就是記憶點，假設我寫了一顆按鈕，然後 commit（動詞），這樣就可以隨時決定是否要回到某個 commit。對了，git 很聰明，commit 記錄的是 diff（有差異的部分），而不是整個專案再複製一份，所以可以大量 commit，不需要擔心。
• Push、Pull：我們剛 commit 完是存在本機的，還沒有送到我們事先約定好的遠端伺服器，push 指的就是上傳到遠端，pull 則是把遠端的拉下來。
• Merge：每個 branch 都是一個時空，總不能永遠平行吧，當一個 branch 上的程式碼完善了，就會 merge 到比較主要的 branch，之後發佈產品的時候，就會從最完善的 branch 編譯出 app。
• Conflict：如果 A 同事跟 B 同事，在自己的 branch 都改動了同一行，當這兩個 branch 要 merge 的時候就衝突了，這就叫 conflict，那該聽誰的呢？git 無法擅自做決定，所以工具會讓我們暫停 merge 的流程，處理完衝突的部分再繼續走完 merge 的流程。
• Pull Request（Merge Request）：這個功能會在存放 repo 的平台上，當我們要 merge 到比較主要的 branch 時，我們會需要請其他協作的同事一起來看自己寫的這些程式碼會不會有問題，這時候還沒有真正 merge，如果沒問題，看完的人就會點擊 merge，如果有問題，就返回修改直到修正。

工具選擇

Android Studio

很幸運的，我們的 Android Studio（或 IntelliJ IDEA 系列 IDE）就有 git，而且還很強大，完全不輸主流 Git GUI（可以按 ⌘+9 打開界面）。

Sourcetree、Fork

既然 Android Studio 已經內建工具，為什麼還要用其他 GUI 呢？

因為如果有多個 repo，可能是寫不同程式語言，用 Android Studio 來管理就太笨重了，不管是什麼 GUI，都只是在幫忙輸入 git 的指令並呈現結果，所以並不需要重學，只要知道這個工具的功能放在哪裡就好，市面上的工具不少，選順手的就好，建議都玩玩看，當工程師後每天都要用。

CLI

比較 hardcore 的做法，要會很多指令，界面也比較不友善，會多花許多時間，也有些人覺得下指令就是工程師的浪漫，如果你相信自己比相信 GUI 多，那就用吧。

要會的指令

git 的指令非常多，如果使用的是 GUI，會用到的指令就少了很多，指令的參數也不需要記憶，但如果要使用 GUI，必須清楚了解每個按鈕按下去會有什麼結果，另外，其實有些指令並不是必須，而是可以用其他指令組合起來達到相同的目的，這邊列舉一些常用、必須會的指令：

• commit
• add
• rm
• reset
• revert
• checkout
• rebase
• pull、fetch
• push
• stash
• branch
• merge
• cherry-pick
• reflog

比較特別的東西

Android Studio before commit

Android Studio 在 git 方面有多一些其他 Git GUI 都沒有的功能，其中一個很好用的，是在 commit 前還能幫忙檢查、做些事。

Android Studio 中顯示 Git Blame

在行數的地方按右鍵開啟。


會顯示出誰在什麼時候 commit，點擊後會開啟該 commit 編輯過的所有檔案，再點擊檔案可以看當時的 diff。

Android Studio 內建 GitHub plugin

這個內建的 plugin 可以做到 create 新的 PR，也可以 review PR。

甚至還能直接 create gist。

流程

每個協作的團隊都有其節奏，什麼時候要在哪一個 branch 上開發、什麼時候 merge、pull 等。

我們要時刻注意流程、自己在哪個 branch 開發，否則會遇到一直在改別人已經改好的東西、改壞別人的東西、難以讓人協同開發等問題。

注意

commit 大小

這是個哲學問題，切 commit 可以有很多理由：

• 按架構，比方說 View、xml。
• 素材、文案。
• 改版號加上版號的 commit message 方便加 tag 及搜尋。
• 風險高，可能會被 revert。
• 還有很多理由。

但不管是什麼理由，不應該該動太多檔案、行數，
但如果是 rename，又會改到一堆檔案，但這卻沒關係，
重點是切開的目的，比方說 PR 容易看、可以容易合併、拔除等。

force push

盡量不要在跟其他人一起協作的 branch 上做 force push，如果對方剛 push 上去就遇到 force push，那他 push 的那些 commit 就會消失，所以要切好 branch，不要共用。

reflog

如果發生 commit 或 stash 被砍掉的事件，可以用 reflog 來挽救，
要注意的是，如果沒有 commit 或 stash 過，就沒辦法找回來。

結語

當工程師每天幾乎都要用 git，難以想象在還沒有 git 的時候，工程師是怎麼做版本控制，我甚至覺得，其他行業也該引入 git 來管理公司的文檔資產。